Policy based system management

ABSTRACT

A computer network includes a plurality of components governed by policies from a policy manager. Where conflicts arise between policies, a conflict management policy is inherent in the system and is implemented to detect and resolve such conflicts.

This application is the US national phase of international applicationPCT/GB03/01331 filed 27 Mar. 2003 which designated the U.S. and claimsbenefit of 02252227.0, dated 27 Mar. 2002, the entire content of whichis hereby incorporated by reference.

BACKGROUND

1. Technical Field

The invention relates to Policy Based System Management especially fordistributed computer systems. The invention further relates to conflictresolution in computer systems.

2. Related Art

Distributed systems are a well known phenomenon for large organisations.Such systems consist of a large number of heterogeneous components andthe systems and their components provide significant management burdensfor system administrators. Various solutions for management ofdistributed systems such as Open View (Hewlett Packard) and TeMIP(Compaq) are available but these require significant manualintervention. As a result as the complexity of the system increases,management capability is further stretched. Most current solutions arecentralised and suffer significantly from heterogeneity problems arisingfrom the use in different distributed systems of different types ofcommunication protocols and methods.

Recently attention has been given to system management based onpolicies, for example the Internet Engineering Taskforce (IETF) policyframework which specifies general requirements for policy basedmanagement and applies it to management of internet routers with theintent of making the configuration more straightforward. The open viewsolution identified above as well as secure policy managers (CiscoSystems) and Policy Based Network Management (PBNM-Intel) all containimplementations based on the IETF policy framework. The existingsolutions, however, assume a single point of control with a centralisedpolicy repository and decision making. The known solutions further focuson specific applications such as network quality of service.

Although the use of policies to specify the behaviour of the system isexpected to have wider applicability than individual items of networkequipment, extending also to software processes running on thisequipment, the existing centralised management approach is not ascaleable solution.

FIG. 1 shows a distributed system designated generally 10 including avariety of sub networks 12, 14, 16 each having a range of components 12a, 12 b, 14 a, 14 b, 14 c, 16 a. The system is controlled from a centralpoint of control 18 which includes a centralised policy manager 20. Theproblem with this type of system is that it is unlikely that all thepolicy-controlled elements will themselves be capable of interpretingpolicies and evaluating appropriate behaviour in response to changingcircumstances. The range of components requiring management may be fargreater than that considered in most policy based management work.

The particular problem with such systems is the relative inflexibilityof the system. Significant front-end manual intervention is oftenrequired when further components are added to the system both inupdating policies relevant to the additional component and in rewritingexisting policies to avoid any conflict problems.

BRIEF SUMMARY

Because a dynamic conflict management policy is implemented, when a newcomponent enters the system it can be accompanied by an appropriateconflict resolution policy without the need to rewrite existingpolicies. As a result the exemplary embodiment can be used to detect andresolve conflicts between actions. In particular a policy structure isdefined to detect and resolve conflict which is supported by the systemgenerally providing generic means for interpreting policies. Theadministrator can set extra policies to define how conflict can bedetected and resolved, for example for each component of the distributedsystem. Conflicts can be detected and resolved on the fly, for livesystems. In particular, the phrase “at run time” refers to the abilityof conflict resolution policies to be added at any stage without havingto cease operation of the system as a whole. If a new policy is addedwhich causes a conflict with another policy and an explicit conflictpolicy rule for dealing with the conflict has not yet been written anddynamically adopted by the components within the system, the conflictresolution mechanism at a local component will still be able to detectthe conflict prior to carrying out either of the conflicting policies,and the details of the conflicting policies are pushed up the tree ofthe system until eventually a high enough level component will resolvethe conflict one way or another using a few over-riding rules (egaccording to the level of priority ascribed to the authors of therespective policies, or according to the age of the policies, etc.). Assoon as a programmer (eg the author of the new policy which has resultedin the new conflict) becomes aware of the possible conflict, a conflictresolution policy may be written and dynamically loaded into the systemwhereupon it will be automatically disseminated to those componentswhich need to know about it, and they will automatically update theirconflict resolution strategies accordingly such that in future suchconflicts can be automatically resolved without requiring the conflictto be pushed up to a high level.

Preferred elements of the present invention, which are set out in thedependent claims, address various problems with known systems. By theprovision of a distributed policy based manager a single point ofcontrol is avoided. System components can delegate (or have delegated bya third party) their policy handling responsibilities to a localinstance of the management agent which will then monitor significantchanges in this system environment, and evaluate and initiate theappropriate control actions. In this way, policy handling is carried outautomatically, close to the managed entities and without the need forcentralized co-ordination. By adopting a flexible, extensible definitionof policy the exemplary embodiment provides a generic means forinterpreting policies and evaluating a desired behavior without specificknowledge of the managed components. The exemplary embodiment takes intoaccount the fact that most network equipment has a considerable amountin common such that many management functions can be widely applied.Even though application software can be very diverse, the managementsolutions provided by the exemplary embodiment provide the relevantflexibility to deal with them,

The preferred implementations of the present invention accordinglyprovide autonomous, and decentralised management accommodatingheterogeneous component management. In the preferred embodiment theinvention uses XML based policies, generally triggered by XML events. Asa result the management agent can manage this system with the help ofevents and policies without the intervention of the outside entity.Because of the nature of XML and in particular as it is text based, itcan be used to communicate with a wide range of heterogeneous systems.

Yet further, by provision of an automated registration step, faster andmore efficient system update and enhancement is available.

BRIEF DESCRIPTION OF THE DRAWINGS

Embodiments of the invention will now be described by way of examplewith reference to the drawings of which:

FIG. 1 shows a policy-based management system according to the priorart;

FIG. 2 shows the basic components of a policy-based approach;

FIG. 3 shows the overall structure of a policy according to theinvention;

FIG. 4 shows a distributed management system according to the presentinvention;

FIG. 5 shows a management agent according to the present invention;

FIG. 6 shows a management agent flow diagram;

FIG. 7 shows the structure for registration of a subject or targetaccording to the invention;

FIG. 8 a shows an event structure according to the present invention;

FIG. 8 b shows a condition evaluation structure according to the presentinvention;

FIG. 9 shows a conflict resolution flow diagram according to the presentinvention;

FIG. 10 shows an example of a system encountering a conflict;

FIG. 11 a shows a route schema;

FIG. 11 a shows conflicting policies in XML;

FIG. 12 shows a conflict resolution structure according to theinvention; and

FIG. 13 shows a distributed management agent in combination with thedistributed system.

DETAILED DESCRIPTION OF EXEMPLARY EMBODIMENTS

In overview, the exemplary embodiment provides a distributedpolicy-based manager where policies are maintained and implements on aseries of management agents distributed around a network, for example aspart of a sub-network. When a new component registers with a localmanagement agent, relevant policies are obtained and stored at the agenta the same time. The component will then be controlled taking intoaccount relevant policies under the management of the local managementagent. In addition, the component will include any relevant conflictresolution policies as part of the policy stored at the local agent. Thelocal agent is also configured to detect conflicts between policies andimplement an appropriate conflict resolution routine taking into accountany stored conflict resolution policies.

In an automated, distributed approach to management, decision makingmust be made based on locally available information and according to aset of rules. These rules, which govern choices in the behaviour of thesystem, are termed policies. Policies allow the users of a system tospecify the behaviour they want it to exhibit. More precisely, policiesallow selections to be made from a range of options provided by thedesigner of a host, router, application or other resource. Theseselections can be specified in terms of a set of conditions withassociated actions. When a policy is triggered, conditions involvinglocally available information can be evaluated and the appropriateactions initiated. This allows flexibility to be built into a system bysupporting a range of different behaviours rather than hard-coding aparticular behaviour—essentially fixing the policy at design-time ratherthan run-time.

A policy-based, distributed approach as provided by the invention allowsconsiderable flexibility in management. Management system components canbe organised in a hierarchy, each with a set of policies controlling itsdecision making. Management issues can be resolved at as low a level aspossible, only referring to a higher level when necessary. In this way,problems of heterogeneity and scale can be handled by a“divide-and-conquer” approach, and speed of response can be achieved byresolving problems locally.

The general structure of a policy is shown in FIGS. 2 and 3. Referringto FIG. 2 first of all, the policy has three principle parts to it,subject 30, target 32 and action 34. The subject 30 and target 32 arecomponents distributed within the system and can, for example, be thesame component. The policy is written to control the subject 30, whichis the entity expected to act on the policy. The policy in particularassociates the subject 30 with the action 34 which should be performedon the target 32.

The overall structure of a policy 40 is shown in FIG. 3.

The top level policy specification consists of six elements. The creatorelement 42 allows the origin of a policy to be established. This policyspecification is intended to be applicable in an environment where thereare multiple points of control. Components should be able to acceptcontrol from users with different privileges. The administrator of arouter, for example, will have ultimate control of its configuration,including the permitted extent of control by other users. End users maybe allowed to control the way the router behaves for their own traffic.Furthermore, as discussed in more detail below, knowledge of thecreators of a number of conflicting policies can allow priorities to beset.

The info element 44 contains most of the information about the policywhich is not directly related to the policy rules. It includes aglobally unique identifier for the policy (“policy-id”) and anindication of the modality of the policy (positive authorisation—whatthe subject must do, negative authorisation—what the subject may not door refrain—what the subject should not do). The intention is that themodality should not be mixed within a single policy. The general policyhandling components of the management system, which have no detailedknowledge of the specific rules contained in the policy, may then takeadvantage of this classification. It may also contain a textualdescription of the policy. The creation time, start time and expiry timeof the policy can also be specified. Finally, a list of policiesreplaced by the current policy may be specified. Policies are consideredto be immutable so different versions are not possible. However, aflexible “data” element is provided as discussed in more detail below.

The sender element 46 identifies the forwarding path the policy hastaken. This information could be used as a check that the policy hasfollowed an expected route, or to establish that the policy has alreadybeen received by other parts of the system. This element may be modifiedbetween creation and receipt of the policy and would therefore not besubject to digital signing.

The subject element 48 identifies those entities (e.g. components) inthe system which are expected to respond to a policy. Identification ofthese entities is done by role. A role is a name for a group (zero ormore members) of related members. This is important so that a policy canrefer to entities which are not present or not known at the time ofcreation if they can subsequently be linked with the role.

The optional trigger element 50 relates an event (via its unique eventtype identifier “event-id” 52) to the policies that are supposed tohandle it. When an event is detected, relevant policies must beactivated. It is assumed that a policy is triggered by a single event.If there is no trigger 50 it is assumed that the policy 40 is activatedas soon as received.

Every policy includes one or more actions elements 54. These specify thebehaviour (action 56) that should result from the triggering of thepolicy 40 (to the targets) which are defined in the action. Each actionselement 54 contains an optional condition expression 60 and a set ofstrings specifying actions (data 62) to be taken on particular targetcomponents. These actions can use the open content features of XMLschema to allow tags appropriate to any particular system to be includedin a policy instance. This is enabled by the data element 62 which can,for example be a reference to a software component and provides a highlevel of flexibility in defining the policy, without requiring rewritingof the whole policy.

The distributed policy-based management system of the invention is nowdescribed in more detail with reference to the local management agentsforming the distributed system. Generally speaking a component (forexample, a subject 30) registers with a management agent, and themanagement agent obtains all the relevant policies and stores themlocally. When an event comes to the system, the management agent simplylooks through the local database and sends the appropriate action(within the policies) to the targets.

A representative management agent is shown in FIG. 4. The agent 70 isassociated with a sub-network 72 of a distributed system having aplurality of Nodes 74. The subnet 72 communicates with the managementagent via a communications channel 76 and an appropriate medium such asthe telephone system 78. Policies and events 80 are received by themanagement agent 70 from the communications medium 78 and can ariseeither from system events or from actions by an administrator 82. Themanagement agent 70 is one of a plurality of agents associated withsub-networks of the full distributed network.

Though the management agent 70 is generic and can be used to manage awide range of distributed components, in this example we considerdynamic routing. We assume there are a number of routers 74 within thesub-network 72 (Node 1-5).

The management agent 70 configures and manages these routers 74. Theadministrator 82 (or other appropriate means) registers the routers 74with the management agent 70 and writes or provide pointers to thepolicies 84 that can be used to configure the routers 74. Once therouters 74 are registered, the management agent 70 downloads all thepolicies (in this case path configuration policies) associated with therouters 74 and configures their communication paths. Let us assume thatthe communication paths are from Node 1 and Node 2 to Node 5 throughNode 3. Once these paths are established the packets should flow throughthe network. But assume further that Node 3 has some limitation on howmany packets it can handle, in other word the Node 3 will get congestedsoon and send a congestion event to the management agent 70 (via thecommunication channel). Now the management agent 70 will retrieve morepolicies associated with the event and send the appropriate actions tothe routers 74. For example the packets will be rerouted via Node 4.

Looking now at the implementation of the invention in more detail, theManagement Agent 70 is an autonomous system to manage the distributedcomponents with the help of policies and events. The policies, which arewritten to manage the components (e.g. nodes 74) are stored somewhere inthe network. Both the target component and the subject components (whichin the example above are the same components), i.e. the nodes 74 need tobe registered with the management agent 70. As a component isregistered, the management agent 70 retrieves all the policies relatedto that component and stores them locally. Now the agent 70 listens(e.g. to an event channel) for the events that are associated with thepolicies. If an event occurs, the management agent retrieves (from thelocal store) the appropriate policies, evaluates conditions, resolveconflicts and send the action(s) to the target components(s).

FIG. 5 describes the overall system and the components of the managementagent 70.

The interceptor 90 is the entry point for the system and initiates allthe components of the Management Agent 70. Since in the preferredembodiment all messages are in XML, the interceptor 90 distinguishesamong different types of messages (policy, event etc) and sends them tothe appropriate component. The interceptor 90 also includes amultithreaded first in first out queuing system for the XML messages.

The basic possible cases intercepted by the interceptor 90 are:

subject delegates—the subject (or some entity on behalf of the subject)delegates its management to the management agent by sending aregistration event. The registration information is stored with thesystem.

Target registers: to target (or some entity on behalf of the target)registers itself with the management agent by sending a registrationevent, so the management agent can locate the target to deliver theactions. The registration information will be stored with the system.

Policy sends to the agent: the policies are sent to the management agent(for example by a policy manager) and if the policies are meant for theregistered subject the policies will be stored.

Events come to the system: for generic events, the event handling getsall the policies and then sends the actions (within the policy) to thetargets after evaluating the condition and resolving the conflict.

When a new policy comes the policy handler 92 checks if the policy issupposed to be triggered by an event or not. If the policy is nottriggered, (i.e. triggerless policy) by an event (e.g. no event code fortrigger) then it sends the policy to the Event Handler component 94 forimmediate execution of policy. If the policy is supposed to be triggeredby an event then it checks whether the subject is registered and thenstores the policy in the local policy store 96. The policy handler 97also registers with the event channel for the event type within thepolicy. If the policy is not for one of its registered Subjects then thepolicy handler 92 discards the policy.

When events come into the interceptor 90 the event handler 94 logs theevent and checks for special events. For example if it is a“registration” event, i.e. event-id is “Registration” and the data partcontains the registration XML then it sends the registration informationto the Registration component 98. If the event is a normal event then itgets all the policies relating to that event from the local policy store96. Then it sends all policies to the condition evaluator 98 to evaluatethe conditions. After condition evaluation it counts all policies and ifthe number of policies is more than one then it uses the conflictresolver component 100 to resolve conflict as discussed in more detailbelow. Once the conflict resolution is done, the actions are sent to thetarget object 34.

The “registration” event is now discussed in more detail. Theregistration relates to subjects/targets which comprise new componentsjoining the system and hence requiring management by the managementagent. Referring to the flow chart in FIG. 6, at step 110 the managementagent in the form of the interceptor 90 intercepts an XML document whichis assessed at step 112 to establish whether it is a policy or an event.If it is a policy the policy handler 92 assesses whether it isregistered and if not the routine ends at step 114.

If at step 114 the policy is registered then at step 118 the policyhandler 92 assesses whether there is an event associated. If there is,then the policy is stored at step 120 in policy store 96. If no event isassociated then the policy proceeds to condition evaluator 98 at step122. The condition evaluator step is described in more detail below.

If the intercepted document is assessed at step 112 to be an event thenat step 122 the type of event is assessed by the event handler 94. Ifthe event is a registration event then the registration information isstored at step 126. For any other type of event all related policies areaccessed from the policy store 96 at step 128. The number of policies isthen counted at step 130. If there are no policies associated with theevent then the routine ends at step 116. However, if there are on ormore policies related to the event then the system proceeds to thecondition evaluator step 132. At step 134 the policies are counted. Ifthere are zero policies then again the system proceeds to the end atstep 116. If there is more than one policies then the conflictresolution element 100 is engaged at step 136. Once the conflict isresolved the resolved policy is implemented and the relevant actions aresent to the relevant targets at step 138. Reverting to step 134 if onlyone policy is counted then the system jumps straight to step 138 andimplements the policy. The routine then ends at step 116.

FIG. 7 shows the structure for registration which relates to theregistration of subjects and targets. Registration comprises a specialtype of event as illustrated in the schema of FIG. 7.

This schema 150 can be used to either register the subject 152 or thetarget 154. Every component (e.g. target 154, subject 152) has one ormore role 156 a,b (e.g. admin, user etc) and one address 158 a,b (tolocate the component). The schema has a pdp_ID 151 allowing uniqueidentities to be adopted for individual management agents. The role isinterpreted as a prioritise list, which may help to resolve conflicts.For this target 154 the system needs some extra information about theactions (also expressed in XML), that can be handled by target 154. Theschema_attributes 160 element can be used for this purpose, for examplethe name 162 and value 164 elements can be used to describe thenamespace and x-path values of the action documents (see the discussionbelow). When a subject is registered the system gets all the policies asgoverned by the role element 156 which bears a policy-id from theexternal policy store and then stores them in the local store 96. TheXML representation of subject registration is shown below.

<?xml version = “1.0”?> <registration xmlns =“http://www.bt.com/management_agent/ registration”   xmlns:xsi =http://www.w3.org/2000/10/SMLSchema-instance   xsi:schemaLocation =<“http://www.bt.com/management_agent/   registration  http://www.bt.com/management_agent/regisration/registration.xsd”>  <pdp_ID>PDP</pdp_ID>   <subject>     <role>Nod X</role>    <address>www.nodex.com</address>   </subject> </registration>

As discussed above, registration on 150 is one event that can beintercepted by the management agent interceptor 90. In addition, as alsodiscussed above, policies can be intercepted for example, policiesloaded into the system by a system administrator and requiringallocation amongst the distributed policy manager. Further still a rangeof events can be intercepted which can, for example, trigger variouspolicies. These are now discussed in more detail.

The structure of an event is shown in FIG. 8 a. Its purpose is toprovide sufficient information to allow generic components to be used inthe distribution of events to all interested entities but also to allowany additional information to be included to support specificcircumstances. An event following the syntax specified here may begenerated either directly or by an XML-aware component or by a specialmonitoring component which obtains information using some othermechanism.

The top level event specification consists of seven elements. Each eventtype has a unique event-id 172, a globally unique string which may beused to trigger appropriate policies. Typically this will be used as akey into a store of policies. The time element 174 identifies when theevent occurred while the optional timetolive element 176 specifies forhow long the event is relevant. Use of this information can allowcertain events to be discarded if not handled in time, limitingunnecessary management traffic. The source element 178 identifies wherethe event originated. The sequence element 180 is an integer which isincremented with each event produced from a particular source. This cansupport partial ordering of events which may be useful, for example, incorrelation of events from a single source. The optional informationelement 182 is a text string intended to be read by people rather thanprocessed automatically. The data element 184 has an open content modeland allows any well-formed XML to be included. This is where anyspecific information about the event can be included, using whateverstructure is most appropriate. The data element 184 agent introduces adegree of flexibility into the schema. As with policy actions, it isonly necessary that the event producer and the interested recipientsshare knowledge of the contents of this element.

The system shown in FIG. 5 further includes a condition evaluator 98 toassist in assessing whether a policy or event meets the relevantconditions.

Conditions are associated with the actions within the policy. Acondition may state for example that, if it is after 6 p.m. then do notallow user X to log in. Some conditions can be evaluated using systeminformation, information within policy or information within event. Butthere may be conditions where the system needs some extra information toevaluate them. This extra information can be sent to the system aspolicies (the action part 56).

A schema 190 has been defined for this purpose, which is shown in FIG. 8b. The condition Evaluator component will try to evaluate the conditionwith the help of all this information.

The role element 192 specifies the target and the condition 194 (whichcan be more than one) describes how to evaluate the conditions. Thefirst operand element 196 can be “Time”, the second operand 198 can be“6 p.m.” and the operator 200 can be equal, greater than etc. The notelement 195 describes the inverse of the whole condition.

When a policy is triggered by an event, the event handler identifies thetargets (from the action expression of policy) then it sends the detailsto the condition evaluator component. The condition evaluator componentlooks for condition_helper 196 policy for that particular target toevaluate the condition. Two further components of the management agent70 requiring further discussion are the local policy store 96 and theevent log 97. The policy store stores the policies preferably in alightweight XML database, for example, XSet and the events are loggedsimilarly using an XSet database. As mentioned above, all of thecomponents of the management agent are preferably configured using XMLpolicies (it is, internal component policies). For example, to aidcondition evaluation or conflict protection and resolution the systemadministrator may set different policies. The use of XSet allows XMLdocuments to be stored and queried easily using local disk and memory.

As mentioned above, a problem with known systems and also withdistributed policy based management systems is that of conflict betweenpolicies. The management agent 70 shown in FIG. 5 further includes aconflict resolution element 100.

The Conflict Resolution component 100 can be used by the ManagementAgent 70 to detect and resolve conflict between actions. Conflictresolution is important for any type of policy driven system. As themanagement of the distributed system should also be distributed, andtherefore lacks a central point of control. One of the implications ofthis is the potential for several administrators to apply policies atmany points throughout the network. Due to this reason conflictresolution is essential for the distributed management system.

Although policy based management has been extensively studied, there arefew conflict resolution techniques/mechanisms available. This is mainlybecause most of the thinking behind the policy based management iscentralised and considered to be managed by single administrators, sothere are few chances for conflicts. There is some consideration of theproblem in “Conflicts in Policy-based Distributed Systems Management” E.C. Lupu, M. Sloman, IEEE Transactions on software engineering, Vol. 25,No. 6, November/December 1999) but this relates to static conflictdetection and resolution, appropriate to a centralised system, and istherefore used on the policies before they are sent to the policymanager.

Turning to the policy structure discussed above, policies are writtenusing XML and the actions can be of any form (i.e. follow any structure,as defined by the data element 62 in FIG. 3). It is possible thatconflict arises within a similar action, referred to here asintra-action or between different actions structures, referred to hereinas inter-action. In the discussion below we deal only withintra-action—if an inter-action issue arose then it would be necessaryto provide an appropriate XML document for the conflict resolutionpolicy—the policy will thus be of variable length and size withdifferent components.

We assume all the components of the distributed system are registeredwith the management agent(s) 70 and the management agent 70 can accessall the available policies. We also assume that each distributedcomponent (the targets 34) has only one (zero or one) conflictresolution policy. Otherwise more than one conflict resolution policy(for the same component/target) will be conflicting with themselves.Whoever sets this policy (the owner/administrator of the component) mustknow about all the actions that can be set for (and handled by) thiscomponent; one policy can cover all potential conflicts.

When the management agent detects more than one policy for a certainevent, it uses the conflict resolution component to detect/resolveconflict. FIG. 9 shows a flow diagram for the conflict resolutionprocess 202, which is described below.

-   1. The conflict resolver 202 tries to retrieve the conflict    resolution policy (203 a) from the policy store 203 b. If no policy    is found then either there is no conflict or the conflict can not be    detected (210).-   2. If the conflict resolution policy is found, then system checks    (204) whether the policy can be used to detect the conflict. If the    policy is not set for this conflict then the process ends there    (210).-   3. If the conflict is detected then the system tries to resolve it,    first by looking at the properties (205) (FIG. 4). These properties    can be used to describe a code (method or dynamically loadable    software) which can be used to resolve conflict (207). The “name” of    the “property” (in the schema, FIG. 10 as discussed below) can be    used to describe whether the code is a method call or a dynamically    loadable code. The “value” of the property can be used to describe    the location of the code (e.g. an HTTP address). In the case of our    route example as discussed below, the conflict can be resolved by    running a separate program that can determine the congestion of    “Node X” and “Node Y” then selects the less congested node.-   4. If the property is not defined then the component looks for the    prioritised list (can be a different policy) of creators (206). If a    list is found the conflict resolver will try to resolve the conflict    (207) by selecting the policy created by the creator with higher    priority.-   5. If the prioritised creator list is not available or it can not be    resolved by the list (e.g. all the creators are same for all    conflicting policies) then the conflict can be resolved by using the    actual conflict resolution policy 208 (i.e. the prioritised value as    in the listing below). If the policy is detected then, by    definition, it will be resolved unless there is a coding or system    error (211).

This hierarchical approach of first assessing the properties field toidentify a conflict resolution mechanism, secondly addressing thecreator field and prioritising accordingly and thirdly, looking to theconflict resolution policy itself ensures that conflicts are dealt withefficiently and consistently. A specific example to which the conflictresolution approach can be applied is now described.

FIG. 10 shows an example router network. Packets coming from Node A 220can take two routes before it can reach Node D 230. One of the routes(through Node X 220) has higher bandwidth because the other route(through Node Y 226) has a radio link 228 (which is considered to havelower bandwidth). FIG. 11 a shows a schema that can be used configurethese routers (Nodes) and FIG. 11 b shows the XML policies (set for NodeB 222) that conforms to the route schema having a route 232, a source234 and Next_Hop 236. One of the actions says if a packet comes fromNode A 220 send it to Node X 224 and the other one says send packet toNode Y 226. Here we may have a potential conflict 244 for Node B 222(“Next_Hop 236”) for the actions (unless Node B 232 is multicasting orbroadcasting). But the system can only detect the conflict (and resolveit) if extra information is available about the conflict.

FIG. 12 shows the conflict resolution policy structure 300 that shouldbe used to set policies for potential conflicts. The elements aredescribed below.

The role 302 defines the actual component (target) of the system whichwill be affected by the conflicting policies. The intra_action 304 isfor the conflicts between the similar structured actions. For ourexample the routing policies (FIG. 11 b) are conflicting with each other(i.e. which route to take). The inter_action 330 is for detectingconflicts within different action structures. For example we can havepolicies where one says “take route through Node Y” and the other says“Take the route with higher bandwidth”. To detect conflict between thesetwo types actions we have to use this structure. The conflicting actionelement 306 for intra-action is described further below with referenceto FIG. 11 b. The property 307 can be used to describe other means (seelater) to resolve conflict.

FIG. 13 shows the structure which will be used to detect conflictingactions. The path_info 308 will identify the location of the conflictwithin the XML document (i.e. the relevant part of the policy), thiscontains the namespace 242 information which is part of the XML header(FIG. 11 b) and the x_path 310 information, for example “Route/Next_Hop”is the path for “Next_Hop” (see Listing 1). The namespace 242 tells uswhere this name (e.g. Next_Hop) has been defined. The name 312 is thename of the entry (in the action policy), e.g. here the name isNext_Hop, The value 314 would be multiple conflicting values for thename, for example here the conflicting policy saying that there is aconflict between values “Node X” and “Node Y”. The action_rank 316 hasan integer value that identifies which conflict should be consideredfirst, e.g. lower value will take preference. Also note that each valueshould be unique.

It will be seen, therefore, how the invention is implemented in XML. Inparticular, the listing at FIG. 11 b represents two conflicting policiesand the approach described shows how the two policies are parsed inorder to determine to conflict. The action rank element 316 isparticularly significant—this identifies the level at which the conflictoccurs and determines that it should be dealt with at that level. Thefirst priority action rank is dealt with first and then it is assessedwhether any conflicts remain—if so then they are dealt with at the nextlevel of priority and so forth until only one policy is left. Thissupports a hierarchical approach to the policy management.

A XML listing for a conflict resolution policy relevant in the presentinstance is as follows.

Listing 1 :− Conflict resolution policy (XML) <?xml version = “1.0”?><!−−Generated by XML Authority. −−> <conflict_resolution xmlns =“http://www.bt.com/management_agent/Conflict_resolutor” xmln:xsi =“http://www.w3.org/2000/10/XMLSchema-instance” xsi:schemaLocation =“http://www.bt.com/management_agent/Conflict_resolutorhttp://www.bt.com/management_agent/Conflict_resolutor/conflict_resolution.. xsd”>   <!−−(role, intra_actions,inter_actions*)−−>   <role>PDP</role>   <intra_actions>    <!−−(conflicting_actions+)−−>     <conflicting_actions>      <!−−(conflicting_action, property*)−−>       <conflicting_action>        <!−−(path_info, name, value+, action_rank)−−>        <path_info>           <!−−(namespace, x_path)−−>          <namespace>http://www.bt.com/management_(—)          agent/Conflict_resolutor</namespace>          <x_path>Route/Next_Hop</x_path>         </path_info>        <name>Next_Hop</name>         <value>Node X</value>        <value>Node Y</value>         <action_rank>1</action_rank>      </conflicting_action>       <property>         <!−−(name,value)−−>         <name>N/A</name>         <value>N/A</value>      </property>     </conflicting_actions>   </intra_actions>  </conflict_resolution>

This represents the detection and resolution phrases discussed above. Ascan be seen the listing is a policy for Intra-actions and includes aproperty field allowing for example down loading of an appropriateresolution sub routine. The path info field defines where the conflictcan be found and also provides the priority (Node X over Node Y) eventthat the conflict resolution policy itself is addressed to resolve theconflict.

Although the discussion above relates to implementation of the inventionusing XML documents, any appropriate implementation can be adopted.

As will be appreciated by those in the art, a method for implementingthis invention can be realized by executing a computer programcomprising processor implementable instructions for causing a processorto carry out the method during execution of the program which may becontained within a computer readable program storage medium.

1. A computer network management system comprising a distributedpolicy-based manager which comprises, for each of a plurality ofsub-networks of said computer network management system, an associatedmanagement agent, each sub-network including a store arranged to storepolicy-conflict resolution policies for one or more components in saidsub-network, wherein each said sub-network management agentincorporates: (i) a sub-network policy receiver configured to receivepolicies from a policy store external to said associated managementagent; (ii) a policy-conflict resolution mechanism arranged in operationto resolve at run time conflicts between different policies received bysaid sub-network policy receiver taking said stored policy-conflictresolution policies into account.
 2. The system as claimed in claim 1 inwhich the policy-conflict resolution mechanism is operable to performconflict detection.
 3. The system as claimed in claim 2 in which thepolicy-conflict resolution mechanism is operable to detect a conflict ifa network event triggers more than one policy.
 4. The system as claimedin claim 1 in which the policy-conflict resolution mechanism is operableto identify a conflict ranking and to resolve the conflict according tothe ranking.
 5. The system as claimed in claim 1 in which thepolicy-conflict resolution mechanism is operable to perform at least oneof the group consisting of: (i) identifying a method or dynamicallyloadable software which can be used to resolve the specific conflict andusing the identified method or dynamically loadable software to resolvethe respective conflict; (ii) identifying a policy creator rank andresolving the conflict according to the creator rank; and (iii)implementing a resolution policy inherent in the conflict managementpolicy.
 6. A method of distributed policy management in a computernetwork which includes a plurality of sub-networks, said methodcomprising: (i) configuring a plurality of interconnected components tohave behavior determined by a plurality of policies; (ii) associating asub-network management agent with each said sub-network; (iii) storingin each sub-network, policy-conflict resolution policies for one or morecomponents in said sub-network; (iv) operating each associatedsub-network management agent to: (a) receive policies from a policystore external to said associated management agent; and (b) determine atrun time if, in respect of any given triggering event, a possibleconflict may arise in respect of one or more of said received policiesactivated by said triggering event and, if so, passing each respectiveactivated policy as an argument to a policy-conflict resolution processoperating, as part of each sub-network management agent, in accordancewith said stored policy-conflict management policies.
 7. The method asclaimed in claim 6 wherein said policy-conflict management policies usedby each management agent differ between different management agents. 8.The method of claim 6 used to implement a computer network manager.
 9. Acomputer network including a computer processor which acts as thecomputer network manager as claimed in claim
 8. 10. A computer-readablecomputer program storage medium containing a program or a suite ofprograms comprising processor implementable instructions for causing acomputer processor to carry out a method comprising: (i) configuring aplurality of interconnected components to have behavior determined by aplurality of policies; (ii) associating a sub-network management agentwith each said sub-network; (iii) storing in each sub-network,policy-conflict resolution policies for one or more components in saidsub-network; (iv) operating each associated sub-network of saidmanagement agent to: (a) receive policies from a policy store externalto said associated management agent; and (b) determine at run time if,in respect of any given triggering event, a possible conflict may arisein respect of one or more of said received policies activated by saidtriggering event and, if so, passing each respective activated policy asan argument to a policy-conflict resolution process operating, as partof each sub-network management agent, in accordance with said storedpolicy-conflict management policies.